Method and an apparatus for computer-implemented evaluation of client business processes

ABSTRACT

The invention relates to a method and a device for the computer-implemented evaluation of electronic business processes using a computer system. In order to check the business process-relevant data contained in a business process (GP) received by the computer system, a static examination of data on the basis of character recognition is carried out in a first step and hypotheses on the content of every examined date are established. In a second step, a dynamic examination of the established hypotheses is carried out. According to the invention, a synchronization of the electronically recognized data contents with client- and/or material-specific data contained in a data base ( 200 ) is performed.

The present invention relates to a method and an apparatus for thecomputer-implemented evaluation of electronic customer businessprocesses and a computer program with programming code which when run ona computer system is adapted to carry out the method according to theinvention, and a storage medium containing a computer program of thiskind.

The term “evaluation” within the scope of this invention comprises therecognition, structuring and working of business processes. Businessprocesses are, for example, orders, delivery plans, invoices, changes toorders, enquiries, etc. These may be processes within the companybetween one department representing the customer and another departmentrepresenting the supplier, and also processes between individualcompanies and their external clients. The processes which can be runusing a system according to the invention include all possible areas ofcommercial and industrial life. In particular, the system according tothe invention is also suitable in conjunction with the control ofindustrial manufacturing and production processes.

In evaluating so-called client business processes human intervention isgenerally necessary at least on one of the two sides involved(client/customer and recipient of the business/supplier). Exceptions tothis are so-called system-to-system processes (S2S processes) in whichtwo company systems matched to one another (ERP systems; ERP: enterpriseresource planning) communicate directly with one another and exchangedata. FIG. 1 shows a diagrammatic representation of the paths ofcommunication in typical customer business processes. On the left handside of FIG. 1 the customer (client) is shown while on the right handside is shown the company receiving the contract (supplier). On bothsides, apart from the above mentioned case of the S2S process, theinvolvement of a human being is generally required. If ERP systems tunedto one another are used on both sides (which is usually onlyeconomically viable with large customers with a high volume of orders),the business processes taking place over the internet or fax may do awaywith the intervention of human agency at least on one side.

Particularly in business processes which use e-mail (electronic mail)and faxes, the problem with human intermediaries is significant.Typically, at the customer end, an e-mail or fax message from one person(generally using a computer, a workstation or the like) is drafted andsent to the supplier. At the supplier end, also, typically the incominge-mail or fax is dealt with by an employee and relevant data is fed intothe company's own system. Thus, data which was originally electronicallygenerated is fed into an electronic data processing device by humanintervention. Only in those cases where the customer uses an electronicform provided by the supplier and set up in accordance with thesupplier's ERP system is it possible to have an incoming e-mail or faxfurther processed directly by the supplier's ERP system.

In a conventional order over the telephone, the customer gives his orderverbally to an employee of the supplier who then inputs this order intothe in-house order system of the supplier. Depending on the structure inthe company accepting the order, the order has to be passed on to anauthorised person before being input into the system and this personthen inputs the order. The customer does not receive an officialconfirmation of the order until the order has been input into thesystem.

In the case of ordering over the internet, (e-commerce solution) thecustomers manually input the information required through a browser.This solution involves additional effort for the customer as thecustomer generally has already recorded the entry in his own orderingsystem and now has to input the entry all over again manually.

In practice, therefore, it has proved extremely difficult to connect theEDP (Electronic Data processing) systems of customers to thecorresponding systems of the supplier. Generally, the customers are notprepared to make the necessary investment in EDP hardware and software.Nor are they usually prepared to adapt their existing and usuallybranch-specific EDP standards to those used by the supplier. Inparticular for potential suppliers with a heterogeneous circle ofcustomers it is also extremely difficult to introduce in-house standardswhich can be matched to customer requirements and to the different EDPsystems of the customers.

DE 197 06 419 A1 discloses a method for controlling business processesusing a technology for mechanical speech processing. In the knownmethod, at least one of the conditions of an activity of the businessprocess is automatically examined.

There are also systems on the market in which, within the scope ofelectronic incoming post processing, incoming business documents arescanned in and then automatically recognised, evaluated and passed on tothe appropriate employee for further processing.

Therefore, the invention provides for a method and an apparatus forcomputer-implemented evaluation of customer business processes havingthe features set forth in claims 1 and 6, and claims 9 and 14,respectively, which allows a user to process incoming business processesfully automatically without human interference on the part of thesupplier, and without the customer having to use data structures orforms provided by the supplier. Orders can be sent by electronic mail(e-mail), by fax or by telephone.

Accordingly, in order to examine data relevant to business processeswhich are contained in a business process (GP) input into the computersystem, in a first checking step the data are statically examined on thebasis of character recognition and hypotheses are drawn up as to thecontent of each piece of examined data, and in a second checking stepthe hypotheses drawn up are dynamically checked. In another embodimentof the invention, in order to examine business process relevant datacontained in a business process (GP) input into the computer system,electronically recognised data contents are compared with customer-and/or material-specific data contained in a knowledge base (200).

According to the invention, for this purpose, the ordering system usedby the supplier (and any other EDP system present including databanks)are combined with an image and/or text recognition system which iscapable of extracting the information and data required from thecustomer forms sent to the supplier and making them directly availableto the in-house ERP system without human intervention.

According to an advantageous embodiment of the invention the orderingsystem used is combined with a telephone (speech) recognition systemwhich recognises speech and/or keystroke information over the telephoneand converts it into digital data which can be processed by the internalordering system.

Preferably, a regular exchange and comparison of data takes placebetween the EDP system of the supplier and the recognition system whichis additionally provided according to the invention, as a result ofwhich the quota of errors in recognising the customer data can bereduced considerably and thus the speed of processing can be improved.

In a further preferably embodiment of the invention, the image and/ortext recognition system capable of identifying the customer and therelevant order details in unformatted orders and other businessprocesses (for example letters written in body copy or e-mails) andconveying them to the in-house system of the supplier. This can be doneby using a databank which is fed from an existing system (e.g. abusiness warehouse system) with information specific to the customerand/or materials. In this way the information and data recognised in anincoming document can be compared and if necessary corrected orsupplemented. The comparison of data takes place using stored data andhistorical information filed in the warehouse system. Using this processlogic the system is capable of independently recognising the customer,for example, and interpreting the contents of the order fully andwithout errors and automatically generating an order for the in-houseERP system. According to the invention, thus, stored data systems andso-called data warehouses (this term referring to large, structured,distributed data stocks of longstanding value and preferably used forqueries and analysis) are connected to recognition systems.

The recognition provided by the recognition systems proceeds in twostages according to the invention. In a first stage there is characterrecognition known per se in which the information sent by a customer isconverted into a format which the in-house system can understand. Thisis done for example using so-called OCR software (OCR=optical characterrecognition), i.e. the optical recognition of clear text. In a secondstage the contents of the document are recognised, i.e. the semanticcontent of the data and information transmitted. This stage ispreferably carried out by a combination of artificial intelligence,semantic text recognition or non-specific comparisons and linking withstored data systems and data warehouses (for historical information).After this, the “knowledge” obtained by the two steps of recognition isconverted into a format which can be understood by the in-house systemof the supplier. The procedure according to the invention describedabove is illustrated in the highly schematic function diagram shown inFIG. 2.

FIG. 3 shows a rather more detailed schematic function diagram in whichthe partial sequences, particularly within the recognition system, areshown in more detail. The recognition system (labelled “system” forshort in FIG. 3) receives a customer business process GP. Optionallywith the (first) customer business process the customer can alsotransmit so-called setup data to the system. These initial setup dataare stored in the system in the knowledge base which includeslearned/historical knowledge. The business process received is examinedby the system, particularly using the data available in the knowledgebase, i.e. learned/historic knowledge and supplier-ERP systeminformation. If the customer business process is recognised (yes) therecognised information is converted into a format which is compatiblewith the in-house ERP system. If the customer business process is notrecognised (no) then manual inspection and amendment of the businessprocess received can be carried out, particularly in the implementationphase of the system according to the invention. The amended version isthen fed back into the recognition system to run the recognitionprocess.

A business process recognised by the recognition system passes through asystem confidence interrogation after conversion into an ERP-compatibleformat. This takes place particularly in the implementation or initialphase of operation of the system according to the invention when therecognition rate is still below a preset threshold. If the recognitionprobability is insufficient (recognition rate<x %) the business processrecognised undergoes further examination before being passed in the ERPsystem of the supplier.

In order to develop the system according to the invention still further,data and information obtained from the recognition process, particularlyrecognised business processes, are stored in the knowledge base(indicated by broken lines in the function diagram). This may be done bystoring the forms or features of forms and the associated recognitionresults, particularly those supplemented by manual intervention, or bytransferring the ordering data generated without the use of orderingforms, i.e. a dynamic improvement of the knowledge base.

The invention also includes computer programs with program coding meanswhich are suitable for performing a method according to the inventionwhen the computer program is run on a computer, and computer-readabledata carriers with computer programs according to the invention storedthereon and computer program products with computer-readable datacarriers of this kind.

Further features and advantages of the invention are described in theclaims and will become apparent from the description and accompanyingdrawings.

It will be realised that the features mentioned above and those to bedescribed hereinafter may be used not only in the combination specifiedbut also in other combinations or on their own without departing fromthe scope of the present invention.

The invention is schematically illustrated in the drawings withreference to additional embodiments and is described in detailhereinafter with reference to the drawings.

FIG. 1 is a schematic view to illustrate the problem on which theinvention is based.

FIG. 2 is a highly schematic functional diagram of the invention.

FIG. 3 shows a more detailed representation of the functional diagram ofFIG. 2.

FIG. 4 shows the different recognition steps according to the invention.

FIG. 5 shows by means of a flow diagram the schematic process forrecognition according to the invention of a business partner in the caseof electronic mail (e-mail).

FIG. 6 shows by means of a flow diagram the schematic process forrecognition according to the invention of the business partner in thecase of a fax message.

FIG. 7 shows by means of a flow diagram the schematic process ofrecognition according to the invention of the type of document or thebusiness process.

FIG. 8 is a schematic representation of the recognition or detection ofthe information requirement.

FIG. 9 is a schematic flow diagram representation showing therecognition according to the invention of information from the businessprocess transmitted.

FIG. 10 shows a schematic overview of a system architecture according tothe invention.

FIG. 11 shows a schematic representation of the structure of therecognition module (Module 100).

FIG. 12 illustrates by means of a flow diagram the method according tothe invention for dynamically recognising the contents of a document.

FIG. 5 schematically shows by way of example the process of recognitionof the business partner/customer in the case of electronic mail(e-mail). The description by way of example starts from a structure ofan e-mail address by the conventional standard, namely user@2ld.tld,where 2ld is the second level domain and tld is the top level domain.(The procedure described is naturally appropriate in those cases wherenot all the customers have been provided with an individual e-mailaddress by the supplier to which orders can be sent as the businesspartner is then tied to the incoming mail address and recognition istherefore trivial. The same is also true of the allocation of individualfax numbers or telephone numbers.)

After electronic mail has been received, the e-mail address of thesender (customer) is compared with the mail addresses stored in thebusiness partner's databank. For the example described here the mailaddress of the sender is “meier@schroeder.de”. If this mail address isstored in the business partner database the business partner isrecognised immediately and the second step “recognition of the type ofdocument/business process” can proceed (see FIG. 4).

If this mail address is not present in the business partner databank thesecond level domain (in the present instance “schroeder”) isinvestigated using the business partner data-bank and optionally thedata stocks in the in-house ERP system (customer list).

If no company is found having the same or similar name or part of thename “schroeder”, in the next step the user name (in this instance“meier”) is investigated. If a customer with the name “Meier” is foundin the data stocks of the ERP system, the company for which he works hasto be compared with the data known from the second level domain. If thecustomer Meier works for a company with the name Schroeco AG, forexample, it can be established by means of the data stored that this isa holding company to which a company Schröder GmbH belongs.

Using subsequent semantic verification or fuzzy analysis aninvestigation is made to see whether Mr Meier of Schroeco AG is likelyto be the business partner sought.

If this third step of checking should also be unsuccessful, as a finalpossibility, the business partner is found by means of a semantic/fuzzysearch through the entire contents of the electronic mail. Theinformation to be recognised may thus also refer to the informationrecognised in another recognition stage.

An analogous procedure takes place when a business process is sent byfax. The recognition process is then carried out on the basis of the faxnumber of the business partner (cf. FIG. 6).

FIG. 7 illustrates the second step “recognition of the type ofdocument/of the business process” in the recognition process accordingto the invention, as shown in FIG. 4. Depending on the particularembodiment, this second step may also be interchanged with the first,i.e. it may take place before the recognition of the business partner.This is particularly advisable when only a few business processes aresupported by the procedure, e.g. during the initial phase of systemimplementation. In the present embodiment, on the other hand, thestarting procedure is as shown in FIG. 4, in which the recognition ofthe type of document or business process is the second step.

In this second step first of all the information as to what businessprocesses the customer has with the supplier/contractor is called upfrom the business process databank. For the company Schroeco AG alreadymentioned by way of example it is found that this company has previouslycarried out the processes “delivery plan” and “order”. A check is thenmade to see whether corresponding examples of documents are present inthe document databank. If they are, a comparison is run to see whetherthe documents received are identical to the documents on file. If thisis the case or very nearly the case, a semantic or fuzzy test is run todetermine whether the present document is an order or a delivery plan,with sufficiently great certainty/probability. The result might then be,for example, that Mr Meier of Schroeco AG has electronically submittedan order.

If there are no documents by way of example or a comparison withexisting documents on file proves negative, a semantic/fuzzy search hasto be run in the text of the message sent to determine the nature of thebusiness process.

In step 3 “establishing the information requirement” (see FIG. 4) atable is used, as shown in FIG. 8 by way of example, to determine whatdata is required to fully recognise the business process (in the presentexample an order) and where corresponding information of value can befound in the data warehouse, for example.

To simplify greatly, it can be assumed here by way of example that thequantity and delivery date are needed to recognise an order completely.Regarding the quantity, information can be used from historic ordersfrom the customer, i.e. Schroeco AG, and product data available from thedatabank such as the minimum order, etc. To determine the delivery datea calendar and also product data available from databanks such as themanufacturing time etc. may be used, for example. The informationobtained is stored in the document databank.

FIG. 9 schematically shows the process sequence of the fourth and laststep of “recognition of the information from the business process”. Theterm “datum” used here is the singular of “data” and therefore means asingle piece of information.

In this recognition step the necessary data are successively extractedfrom the document sent. The first datum to be extracted in theembodiment by way of example is the delivery quantity. In accordancewith the table provided in the document databank, a search is run inhistoric order data of Schroeco AG and it is found for example that in90% of cases Schroeco AG order a quantity of 20 tons and in only 10% ofcases do they order a quantity of 10 tons. From the ERP or anotherdatabank it is found that 10 tons constitutes the minimum order. On thebasis of this finding the information that Schroeco AG are ordering 20tons is extracted by semantic recognition and/or artificialintelligence/fuzzy interrogation.

The second datum to be extracted in this embodiment by way of example isthe delivery date. In accordance with the table previously drawn up inthe document databank, orders before the present day are excluded andwith a manufacturing time of 10 days (obtained from the databank) anorder for the period beginning in 10 days is considered to be mostlikely. Using semantic recognition and/or artificial intelligence/fuzzyinterrogation the information that Schroeco AG would like a delivery inthree weeks time is extracted on the basis of this finding.

EXAMPLE AND ALGORITHM

With reference to an embodiment shown in FIG. 10 relating to orderrecognition, an EDP and software system according to the invention forfully automated recognition of customer orders and for transferring theread and recognised orders into an ERP (Enterprise Resource Planning)system e.g. of type SAP R/3 will now be described.

The system according to the invention comprises the modules described inmore detail hereinafter, namely a recognition module 100, a knowledgebase 200, an enhancement module 300, a transmission module 400 and anERP system 500.

The recognition module 100 serves to recognise the necessary data togenerate a business process (such as an order) in an ERP system. It isassumed that not all the data which have to be entered in order togenerate a business process (for example an order) in an ERP system haveto be recognised but rather the data to be recognised can be completedfor example by material stock data and customer profile data.

The components of the recognition module 100 are as follows:

-   -   110: System for optical character recognition (OCR) based on an        input file    -   120: System for static data recognition or for forming        hypotheses as to specific file contents    -   130: Rules for supporting the activity of component 120    -   140: System for dynamic data recognition based on verification        of the hypotheses formed by component 120    -   150: Criteria and rules for supporting the activity of component        140    -   160: Output device

Module 200 (knowledge base) serves to support the activity of therecognition module 100. The module 200 is a knowledge base in the formof a databank or a two-directionally responsive ERP system.

The components of the knowledge base 200 are as follows:

-   -   210: Stock data relating to materials which can be ordered, i.e.        data on an assortment of relevant items    -   220: Stock data relating to business partners, i.e. profiles of        possible customers (containing for example information on        customer lists with associated identifying numbers, addresses,        ordering habits, special requirements, etc.    -   230: Data on historical orders from relevant business partners        (customer history)

The enhancement module 300 serves to manually enhance output data setsfrom module 200 which have not been fully recognised.

The transmission module 400 serves to enhance and reformat the data setrecognised from module 200 or module 300 into a format which can beimported by the ERP system used. This is done, for example, usingbusiness integration software of the TSI Mercator® type.

The components of the transmission module 400 known per se are asfollows:

-   -   410: System for enhancing the output data set received from        module 200 or 300 into a data set with all the data which have        to be entered in order to generate a business process (such as        an order) in an ERP system.    -   420: Module for converting the complete data set into a format        which can be imported by the ERP system used.    -   430: Output component for transferring the formatted data set to        an ERP system

The module designated 500 is an ERP system, for example of the SAP R/3type.

The components of the ERP system 500 are as follows:

In addition to the usual components of an ERP system the followingcomponents are essential:

-   -   510: Interface for receiving a data set as transferred from        module 400    -   520: Interface for delivering the data described under module        200 to a knowledge base as described in module 200

DESCRIPTION OF THE FUNCTION OF THE MODULES

The individual modules and their components and their functions will nowbe described in detail. For recognition of other business processes suchas changes to orders, cancellations of orders, invoice processing etc.the system described can also be used according to the invention,suitably modified.

The recognition module 100 accesses a file in the component “characterrecognition” 110 and converts the information contained in this fileinto a text file (see FIG. 11). Input formats form image files, forexample, of the types BMP, BW, DCX, DIB, EMF, GIB, GIF, TIF, ILBM, JFIF,JIF, JPEG, LBM, PCD, PCS, PIC, PIX, PNG, PSD, RGB, RLE, SGI, TGA, TIFFor WMA, Postscript and Reader files, e.g. of the postscript or AdobeAcrobat Reader file types, markup language files such as HTML or XMLfiles, document files from wordprocessing systems, e.g. MicroSoft Worddocuments, text files e.g. of the ASCII type or Rich Text format. Therecognition module 100 recognises the contents of the texts contained inthese files as best it can and converts them into a text format, e.g. ofthe ASCII or Rich Text format type. To do this, the files are read in byoptical character recognition (OCR) systems known per se andcommercially available, e.g. of the aCE Docustar type, and are issued orreformatted as ASCII or Rich Text format files.

In the “static recognition” component 120, hypotheses as to the data tobe recognised are developed from the file resulting from the characterrecognition 110. To do this, the component “Rules” 130 provides a rulemechanism with two types of rules: on the one hand rules for formattingthe fields to be found (example: the date of order has the format(DD/MM/YYYY) or (DD/MM/YY) or (DD-MM-YYYY) or . . . ) and on the otherhand rules as to the semantic context of the information relevant todeveloping the hypothesis [example: “the order number is often foundclose to the sequence of characters (order number)” or “the date ofordering is always before the desired delivery date”]. From this, thecomponent “static recognition” 120 draws up hypotheses such as forexample: “desired order quantity equals 10 kg”. For each datum to berecognised by the module 100, a number of (possibly contradictory)hypotheses may be formed [example: hypothesis 1 (order quantity):“desired order quantity=10 kg”, hypothesis 2 (order quantity): “desiredorder quantity=10000 kg”].

The hypotheses are sent for checking to component “Dynamic Recognition”140 which examines the hypotheses obtained from the “Static Recognition”120 using criteria and rules from the “criteria/rules” component 150 andreferring back to the knowledge base 200. The corresponding checkingalgorithm is shown in FIG. 12.

The elements in the algorithm shown are defined as follows:

-   -   Recognition steps (resulting in the recognition of a desired        datum): R        -   →Counting: i; i ε {1, . . . , i_(max)}    -   Hypothesis for a possible value of R_(i) from the preceding        process step (component 120): H(R_(i))        -   →Counting: m; m ε {1, . . . , m_(max)}    -   Exploratory test criterion for hypothesis H_(m)(R_(i)): j(R_(i))        -   →Counting: n; n ε {1, . . . , n_(max)}    -   Confirmatory test criterion for hypothesis H_(m)(R_(i)):        k(R_(i))        -   →Counting: p; p ε {1, . . . , p_(max)}

The criteria in component 150 are divided into two categories: on theone hand into criteria which may be used for exploration (exploratorycriteria j) and on the other hand into those which can be used not forexploration but only for confirmation (confirmatory criteria k). Thecriteria are arranged in a hierarchy within their category with thesharpest criterion of the category being first (j_(l)(R_(i)) ork_(l)(R_(i))), the sharpness of the criteria increasing as the indexnumber rises.

The criteria may be examined according to the module construction orcriterium by a sharp yes/no query (possible results would be referred tohere mathematically as 0 or 1) or by fuzzy logic. In the latter case theassociation of the hypothesis to be tested with a fuzzy quantity definedby the rule of the criterion and any associated data from the knowledgebase can be stated in standardised terms by a value in the range [0,1].For each criterion a confidence interval, i.e. a range within theinterval must then be specified for which the hypothesis withstands thecriterion when the value of the association with the fuzzy quantityfalls within this range.

For the first (i=1) datum (R₁) to be found a check is carried out tofind whether there are more than zero hypotheses [H_(m)(R₁)]. If this isnot the case the recognition of R₁ has failed. A check is made as towhether other data to be found are missing. If this is the case theprocess is continued with the next datum (in this case R₂), otherwisethe process is at an end.

If there are more than zero hypotheses [H_(m)(R₁)] the compatibilitywith the first exploratory criterion (j₁(R₁)) is tested for allavailable hypotheses one after the other. Any hypotheses which are notcompatible with the criterion are rejected. After all the hypotheseshave been tested the remaining hypotheses [H_(m)(R₁)] are counted. Ifthe hypothesis count is more than 1 and other exploratory criteria areavailable, the check is repeated with the next lower criterion in thehierarchy. If no other exploratory criteria are available or if thehypothesis count came to 0 the recognition of R₁ has failed. A test isrun to see whether other data to be found are absent. If this is thecase the process is continued with the next datum (in this case R₂),otherwise the process is at an end.

If the hypothesis count was 1, this means that a potential solution wasfound. This is tested hereinafter with any other exploratory criteriaand the confirmatory criteria. For this purpose a check is made as towhether all exploratory criteria have hitherto been used. If not,compatibility with the next lower exploratory criterion in the hierarchyis checked. If there is no compatibility recognition of the datum (inthis case R₁) has failed. A check is made as to whether other data to befound are missing. If this is the case the process is continued with thenext datum (in this case R₂), otherwise the process is at an end. Thisloop is run until the exploratory criterion at the bottom of thehierarchy has been used.

Then a check is made as to whether a confirmatory criterion is present.If this is not the case recognition of R₁ has succeeded. The hypothesisremaining is assigned a solution value (for example: the customer Meierwas clearly found to be a customer, the hypothesis customer=Meier isassigned the customer number of the customer Meier from the database). Acheck is then made as to whether other data to be found are absent. Ifthis is the case the process is continued with the next datum (in thiscase R), otherwise the process is at an end.

If at least one confirmatory criterion is present the compatibility ofthe hypothesis with the confirmatory criterion at the top of thehierarchy (in this case k₁(R₁) is tested. If there is no compatibilitythe recognition of the datum (in this case R₁) has failed. A test is runas to whether other data to be found are absent. If this is the case theprocess is continued with the next datum (in this case R₁) otherwise theprocess is at an end.

If compatibility is found, a check is made as to whether there are otherconfirmatory criteria. If this is not the case the recognition of R₁ hassucceeded and the process is continued as described above. If there areother confirmatory criteria the compatibility of the hypothesis with theconfirmatory criterion which is the next one down in the hierarchy (inthis case k₂(R₁)) is tested. This loop is run through again until itcomes to an end.

The process described with reference to the first run-through isrepeated for all the data to be found.

The criteria used refer in content to the data in the knowledge base(component 200). Thus, for example, a criterion in the search for thecustomer (example: R₁=customer) may run as follows: “the company namespecified in the hypothesis is found in this form or in a similar formin the customer list in the knowledge base”.

The data to be found and also the criteria should be in a hierarchicalorder so that during recognition reference can be made to the results ofprevious partial processes and in this way the complexity can be reducedand the probability of recognising a specific datum can be increased.

If for example the customer has already been found, a criterion foridentifying the receiver of the goods (example: R₂=receiver of goods)might run as follows: “the company address specified in the hypothesisis found in the customer list in the knowledge base in this form or in asimilar form and, if Rl has been successfully found, in the list ofaddresses of receivers of goods associated with this customer”.

Output module 160 checks whether all the data to be found (R₁ toR_(max)) have been found by the component “Dynamic Recognition” 140. Ifthe answer is yes, the data found (R₁ to R_(max)), are passed on to thetransmission module 400, and if not they are passed on to the module 300for manual enhancement.

As an illustration, a simple example with fictional data, hypotheses,criteria etc. will be described more fully:

R₁ is the customer (sold-to), R₂=R_(max) is the receiver of the goods(ship-to).

Rules in module 130 state that it must be a sequence of lettersbeginning with a capital letter. In the document converted into a fileby module 110, module 120 finds the words “Meier”, “Muller” and“Schulze” which conform to this rule. These names therefore form thehypotheses: H₁(R₁): customer=“Meier”, H₂(R₁): customer=“Muller”, H₃(R₁):customer=“Schulze”.

The first exploratory criterion might be: the customer specified in thehypothesis is present in the customer databank in the knowledge base(module 200). For the first hypothesis the check finds a “Meier GmbH” inthe knowledge base. Fuzzy testing produces a value of for example 0.8for the correctness of the value “Meier” from hypothesis H₁(R₁). As theconfidence interval for this criterion is 0.6 to 1, the hypothesisstands up to examination.

With H₂(R₁) only the value “Obermüller AG” is found, which is given amarking of 0.4. Thus the results are outside the confidence limits.Hypothesis H2(R1) is therefore rejected.

With H₃(R₁) the hypothesis again holds, which means that 2 hypothesesare left.

The second exploratory criterion would result in only the hypothesisH₁(R₁) remaining, analogously to the procedure described above. MeierGmbH would thus be accepted as the customer. However, there is still oneexploratory criterion left. This would be applied to Meier GmbH. MeierGmbH also stands up to this criterion. Thus, the exploratory criterionhas been so-to-speak converted into a confirmatory criterion. Otherexploratory criteria would also be used accordingly before the checkingof Meier GmbH with the confirmatory criteria was continued. If thehypothesis also stands up to this, the recognition of R₁ is true and theresult is the customer number of Meier GmbH, such as “4711”. A systemdesign is also possible in which the confirmatory use of criteria with anegative test result does not immediately lead to rejection of thehypothesis but goes into an evaluation parameter of the hypothesisquality which is compared with a corresponding confidence interval afterall the criteria have been gone through and only results in rejection ofthe hypothesis below a confidence threshold.

Exactly the same procedure is followed for R₂ except that here theinformation that Meier GmbH is the customer can be used. In searchingfor the receiver of the goods the knowledge base can be restricted, forexample, to the receivers of the goods associated with customer 4711,namely Meier GmbH.

If a customer were found, output component 160 would establish that boththe elements looked for have been found. The information would then bepassed not to module 300 for finishing but to module 400 for furtherprocessing.

The workstation module 300 receives from the output 160 of the module100 the data sets in which not all the data have been fully recognised.The operator has the option of manually checking on any unrecogniseddata fields on screen. For this purpose the system supplies him with theoriginal document either as a soft copy, i.e. on screen, or as a hardcopy, e.g. in the form of a paper printout, depending on the systemdesign. The operator then has the opportunity to work out what value hasto be entered into the corresponding field and inputs the correspondingdata into the module 300. Depending on the design of the module he maybe offered a choice of options based on the hypotheses generated incomponent 120. Once the amendment has successfully made the workstationmodule 300 passes the data on to the transmission module 400.

If for example the quantity ordered has not been determined, theoperator looks for this in the original document and adds it to the dataset using the interface in the work place module 300. If no other dataare missing the module then passes the data on to the module 400 asdescribed.

The transmission module 400 receives the completed data from the module100 or 300. Depending on the system design, in some cases, the data arenot complete enough to allow a business procedure, in our example anorder, to be initiated in an ERP system. Component 410 enhances the datarecord using information defined as essential in a combination of dataas in the data set. This might be for example a warehouse which has tobe used for a specific customer-product combination, in order todispatch the goods.

After the data set has been enhanced it has to be converted in component420 into a format which the ERP system is capable of processing inmodule 500. If for example a SAP R/3 type system is used in module 500,component 420 converts the data set into an SAP Intermediate Document(IDoc), for example.

Component 430 sends the results to the ERP system and in the embodimentdescribed it thus sends the IDoc to the SAP R/3 system.

The ERP system (Module) 500 describes an ERP system which has at leastthe conventional commercial functions. An example of such a system isthe model R/3 made by Messrs SAP.

The ERP system must be capable of receiving data sets which it obtainsfrom component 430 for processing. For this it needs an interface whichprocesses the format generated, in this particular instance an interfacewhich can process IDocs (component 510). As the other functions are notpart of the system described here but are commercially available thereis no need to describe them further at this point. An exception iscomponent 520: the knowledge base (module 200) has to have thepossibility of accessing the defined information from the ERP system.Depending on the design of the system this is done by direct (online)access of the knowledge base to the data maintenance in the ERP system,i.e. for example the data warehouse of SAP, or through a periodic oroccasional download of the relevant information directly into thedatabank of the knowledge base. It must therefore be ensured that thedata warehouse required is supplied with the necessary data from module500.

In the case of an order over the telephone according to the inventionthe following procedure is adopted according to a preferred embodiment:

The system according to the invention comprises an interactive callanswering device known per se which welcomes the customer as he callsand takes him through the ordering procedure, wherein the customer'sdetails are acquired by keying in or speech.

The customer quotes, in the correct order, his customer number and/or anidentification and authorisation number (PIN), and it should be notedthat the invention will also operate without the PIN number on the basisof the recognition system described above.

The customer can then state whether this is a new order or a follow-upto instructions which have already been placed (amendment orcancellation). In the case of a new order the customer quotes the goodsreceiver number, customer order number, item number, desired quantityand desired delivery date. In the case of a change to an order orcancellation the customer quotes the order number which the supplier hasalready provided him with at this time and says whether it is a changeor a cancellation. If there is a change he then specifies the new amountand/or a new delivery date.

According to the invention, the customer then hears a summary of theinformation he has provided. In the event of a spoken order his recordedspeech is “played back” by the call answering machine, i.e. replayed,while in the event of an order which has been keyed in the customerhears a spoken message which is electronically generated by thekeystrokes. The customer then has the opportunity to make any changes,place further orders and/or confirm the order.

Once the telephone ordering process has ended the customer details aretaken into the in-house ordering system and checked for the plausibilityof the instructions as explained in detail hereinbefore. Once the checkhas been run the customer receives an automatically generatedconfirmation of the order by electronic mail or fax.

According to a particularly advantageous embodiment of the invention,the telephone details provided by the customer are checked in parallelwhile the order is being placed so that even during the telephoneordering process the customer can be given automatic feedback to saywhether his order (or request for a change or cancellation) has beenaccepted and the job number which the instructions have been allocated.

Another possible alternative is for the customer to telephone to enquireas to the status of his order, by quoting the job number which he willknow by this time and receiving from the ordering system (ERP system) areply as to whether the order is still outstanding (i.e. not yetproduced or dispatched), has been allocated (i.e. has been produced butnot yet sent out) or has already been sent out.

The invention thus makes it possible for customers using a continuoustext, otherwise unformatted text, the telephone or even using their ownorder forms, to carry out business processes which can be fully andcorrectly recognised at the supplier end and further processed with noor only minimal human intervention.

1-12. (canceled)
 13. Process for the computer-implemented evaluation ofelectronic business processes using a computer system, wherein in orderto check business process-related data contained in a business process(GP) input into the computer system, electronically recognized dataelements are compared with customer- and/or material-specific datacontained in a knowledge base (200), comprising the following steps:converting or reformatting the data contained in the input businessprocess (GP) into a text filed, in a first checking step, carrying out astatic check on the data on the basis of character recognition anddrawing up hypotheses as to the contents of each datum checked by takingonto account rules on the semantic context of information relevant tothe drawing up of the hypotheses, in a second checking step, carryingout a dynamic check of the hypotheses elaborated using stored criteriaand rules, with reference to the knowledge base (200).
 14. Processaccording to claim 13, wherein if a recognized business process-relateddatum does not agree with data in the knowledge base (200) the businessprocess-related datum is corrected on the basis of the contents of theknowledge base (200).
 15. Process according to claim 13, wherein thebusiness process (GP) is passed on to an enhancement module (300) formanual enhancement, if a correction cannot be made on the basis of thecontents of the knowledge base (200).
 16. Process according to claim 13,wherein business processes are input electronically by electronic mail,fax, OCR character recognition and/or telephone.
 17. Process accordingto claim 13, wherein recognized business process-related data areautomatically passed on to a job processing system (500) which runs thebusiness process fully automatically on the basis of these data. 18.Computer system for computer-implemented evaluation of electronicbusiness processes, having an input interface, a recognition module(100), a knowledge base (200), a transmission module (400) and a jobprocessing system (500), wherein in order to check businessprocess-related data contained in a business process (GP) input into thecomputer system via the input interface, electronically recognized dataelements are compared with customer- and/or material-specific datacontained in a knowledge base (200), while first of all the datacontained in the input business process (GP) is converted or reformattedinto a text file and in order to check business process-related data inthe text file in the recognition module (100), in a first checking step(120), a static check is carried out on the data on the basis ofcharacter recognition and hypotheses are elaborated as to the contentsof each datum checked, taking into account rules on the semantic contextof information relevant to the drawing up of the hypotheses, informationrelevant to the drawing up of the hypotheses, and in a second checkingstep (140), a dynamic check is carried out on the hypotheses elaboratedusing stored criteria and rules, with reference to the knowledge base(200).
 19. Computer system according to claim 18, wherein if arecognized business process-related datum does not agree with data inthe knowledge base (200) the business process-related datum is correctedon the basis of the contents of the knowledge base (200).
 20. Computersystem according to claim 19, which further comprises an enhancementmodule (300) used for manually enhancing business process data if acorrection to the business process-related datum cannot be made on thebasis of the contents of the knowledge base (200).
 21. Computer systemaccording to claim 18, wherein business processes are inputelectronically by electronic mail, fax, OCR character recognition and/ortelephone.
 22. Computer system according to claim 18, wherein businessprocess-related data recognized by the recognition module (100) areautomatically passed on to the job processing system (500) by thetransmission module (400) and the job processing system (500) runs thebusiness process fully automatically on the basis of these data. 23.Computer program product having a computer-readable medium and acomputer program stored on the computer-readable medium, with programcoding means which are adapted to execute a process according to claim13 when the computer program is run on a computer system.
 24. Computerprogram with program coding means, which are adapted to execute aprocess according to claim 13 when the computer program is run on acomputer system.